Hermes Agent 变身 Codex，下一代 Agent 拼的是多端续航
Anton Coding Anton Coding 2026年6月4日 18:17
Hermes Agent 真的开始变得像 Codex 了。
这句话听起来有点反直觉。
在很多人的印象里，Hermes 更像一个活在消息端的 Agent：你在飞书里叫它，它能接任务、调工具、跑流程、回消息。Codex / Claude Code 则是另一类东西：打开项目目录，处理复杂工程，坐在桌面上写代码。
但 Hermes Desktop 发布后，这条边界开始变模糊。
它不再只是飞书里的 Agent。它开始进入桌面端，打开项目目录，坐到 Codex / Claude Code 熟悉的位置上。
所以这件事表面看是一个新客户端发布，实际更像一个信号：
下一代 Agent 拼的不是单点能力，而是多端续航。
Agent 不能只在一个入口里强。它要能在消息端接住需求，在桌面端处理复杂任务，在项目目录里执行代码，再把结果回到协作场景里。
这才是 Hermes Desktop 这次真正抛出来的问题。
Hermes 怎么突然变成 Codex 了
先说事实。
Hermes Desktop 上线以后，Hermes 有了一个更接近 Coding Agent 的桌面入口。
它可以像 Codex / Claude Code 那样进入项目目录。原来配置过的 session、channel、model 等也会保留下来。Messaging、Skills & Tools、SOUL.md、项目目录切换这些入口，也都出现在桌面端。
这意味着它不是单纯换了一个壳。
它把原来 Hermes 的一部分“消息端 Agent”能力，搬到了桌面执行现场。
以前你可能在飞书里和 Hermes 交互，让它做轻量任务、跑脚本、处理资料、调用工具。现在它开始坐到桌面上，做更接近 Codex 的事情。
所以我愿意用一个更直接的说法：
Hermes Agent 变身 Codex。
但这句话不是说 Hermes 已经替代 Codex。
它真正有意思的地方是：一个原本更偏消息端的 Agent，开始补上桌面端执行能力。Agent 正在从“一个入口里的助手”，变成“跨入口续航的工作系统”。
真正的变化是 Agent 开始跨端续航
过去我们很容易按入口理解 Agent。
在飞书里的，就是消息 Agent。
在 IDE 或桌面项目里的，就是 Coding Agent。
在终端里的，就是命令行 Agent。
这种分类很自然，也很方便。但真实工作不是按工具边界发生的。
一个需求可能先在飞书里聊出来。中间要查资料、定边界、改方案、确认取舍。到了真正执行时，又要进入桌面项目目录，读代码、改文件、跑测试、看报错。
如果每一个入口背后都是一个互相陌生的 Agent，工作流就会断。
不是因为它们不强，而是因为它们各自只强在一段。
飞书里的 Agent 很适合随时调度。桌面 Coding Agent 很适合处理复杂工程。终端 Agent 很适合跑命令和看系统状态。
但一个人的工作流需要的不是“每段都有一个强工具”，而是这几段能不能接得上。
这就是我说的多端续航。
多端续航不是到处都能打开一个聊天框。
它更像一块电池：需求从一个入口开始，任务换到另一个入口继续，中间的上下文、偏好、工具能力和历史记录不掉线。
我的真实分工，正好说明为什么需要续航
过去几个月，我自己的使用方式其实很分裂。
复杂 Coding 任务，我会交给 Codex。
简单 Coding 任务，很多时候直接在飞书上操控 Hermes 完成。
这个分工很顺手。
Codex 适合重工程。Hermes 适合随时叫起来，处理轻量任务、衔接消息端的工作。
但这个分工也暴露了一个问题：产品相关的讨论经常发生在 Hermes 里，真正编码时又切到 Codex。
两个工具都好用，问题是它们之间不一定能续上。
飞书里聊过的需求边界、方案取舍、历史偏好、上下游判断，到了另一个 Agent 里，往往要重新交代。
这不只是复制 prompt 麻烦。
真实工作里，最关键的信息经常不是写在某一段文字里的，而是在反复讨论中形成的共识。
为什么这个功能不能按第一版做。
为什么这里要避开某个边界。
为什么用户真正要的是一个场景闭环，不只是一个功能点。
为什么这个项目里某个历史包袱不能碰。
这些东西很难完整搬运。
所以我现在看 Hermes Desktop，不会只看它界面像不像 Codex，也不会只看它能不能打开项目目录。
我更关心的是：它能不能把飞书端沉淀下来的那部分工作记忆，续到桌面端的执行现场。
多端续航不是多几个客户端
很多产品都会说自己支持多端。
网页能用，桌面能用，手机能用，这叫多端入口。
但对 Agent 来说，光有入口不够。
因为 Agent 不是普通软件。它的价值不只是“在哪里打开”，而是“它是否认识你正在做的事”。
一个真正有续航能力的 Agent，至少要接住几层东西。
第一，是同一套 profile 和长期偏好。
它要知道你是谁，你习惯什么风格，哪些事不能做，哪些流程要等确认，哪些工具优先使用。
第二，是同一套 skills 和工具能力。
你不希望在飞书里已经训练好的流程，到了桌面端又重新教一遍。
第三，是历史 session、channel、model 这些工作状态。
如果一个 Agent 在不同端口之间完全失忆，多端只是多个孤岛。
第四，是任务结果能回流。
桌面上执行完代码、生成文档、跑完检查，最好能自然回到消息端，让协作继续发生。
所以多端续航不是“做一个桌面版”。
它的本质是：同一个 Agent，带着同一套记忆和能力，在不同工作场景里接着干。
这也是 Hermes Desktop 这次让我觉得有看点的原因。
它不是从零做一个 Coding Agent。
它背后原本就有 profile、memory、skills、tools、messaging、cron、gateway 这些系统。现在桌面端加入以后，Hermes 开始有机会把“消息端调度”和“桌面端执行”放进同一条链路里。
Codex 仍然强，但 Hermes 的变量不同
这里不用硬踩 Codex。
我现在仍然会把复杂 Coding 任务交给 Codex。原因很简单：它在复杂工程任务上足够强，使用习惯也已经形成。
Hermes Desktop 现在要证明的，不是标题里喊一句“变身 Codex”就够了。
它要证明的是另一件事：当一个 Agent 原本就活在消息平台、长期记忆、skills、工具调用和自动任务里，它进入桌面端以后，能不能把这些东西带到 Coding 场景里。
如果做不到，它就是一个新的桌面客户端。
如果做得到，它和 Codex 的差异就不只是“谁更会写代码”。
它争的是一个更上游的位置：从需求入口续航到执行入口。
Codex 强在编码现场。
Hermes 的变量在于，它原来就离需求现场更近。
飞书里的讨论、群聊里的任务、日常调度里的偏好、长期沉淀的 skills，这些东西如果能带进桌面 Coding 场景，Hermes Desktop 的意义就会变大。
因为很多代码问题，并不是从代码开始的。
它们先从一个模糊需求开始，从一次产品讨论开始，从一个没说清楚的边界开始。
谁能接住这些前置信息，谁在后面的执行里就更有机会少走弯路。
下一代 Agent 拼的是多端续航
所以我不太想把 Hermes Desktop 写成一个普通发布新闻。
“它支持哪些系统”“怎么下载安装”“界面有什么按钮”，这些当然有用，但不是这件事的核心。
这件事更像一个趋势样本。
Agent 过去拼的是单点能力：谁会写代码，谁会调工具，谁能联网，谁能读文件，谁能跑命令。
接下来会拼另一件事：谁能陪你跨过完整工作流。
从飞书里的一个需求开始，到桌面项目里的代码改动，再到执行结果回到消息端，中间不要断。
从一个临时任务开始，到长期记忆、技能沉淀、复用流程，中间不要断。
从轻量调度开始，到复杂工程执行，中间不要断。
这就是多端续航 Agent 的价值。
它不是让你多装一个客户端，而是让 Agent 不再被某个入口困住。
现在最该验证的是续航能力
当然，现在还不能直接下结论。
Hermes Desktop 要不要真的放进主力工作流，还得拿重活测试。
我最想看的不是界面像不像 Codex，而是几个更实际的问题：
复杂项目能不能接住。
飞书端和桌面端的上下文能不能顺着走。
skills、tools、memory、session 能不能在真实任务里形成连续体验。
执行结果能不能自然回到消息端和协作场景。
这些问题跑通了，Hermes Desktop 才不只是一个桌面端。
它代表的是 Agent 工作流的一种新形态：
Agent 的下一步不是变强一个端口，而是学会跨端续航。
Hermes Agent 变身 Codex，这个标题听起来像是工具变形。
但我更愿意把它看成一个趋势信号。
下一代 Agent 的竞争，不会只发生在 IDE 里，也不会只发生在聊天框里。
它会发生在你每天切换的那些工作入口之间。
谁能不断线，谁才可能真正留下来。
AI · 目录
继续滑动看下一个
Anton Coding
向上滑动看下一个